20. When using CodeWarrior IDE v2, I can't open my projects and I get an error of -5000 everytime I make the attempt. How do I fix this?

MW Visual SourceSafe doesn't recognize the Settings.stg and .tdt mask types as part of your project. To correct, you need to add the line:

     Relevant_Masks = !*.stg, !*.tdt 

To either your srcsafe.ini file or your ss.ini file. Add the line to your srcsafe.ini file if everyone on the project is using the CodeWarrior IDE v2 application for development work. If only some individuals are using the v2 version of the IDE, then just add the line to their personal ss.ini files.

21. Can I use the tilde (~) character in a filename?

Yes, but we recommend that you don't.

Within MW Visual SourceSafe and Microsoft SourceSafe, the tilde character is used in two ways. The first denotes a version range (-vd11/2/96~ljust_because). The second compresses filenames so they will fit into a give n namespace. It is this second case where trouble can occur.

When the short name (the one stored at the parent's database record header) is generated, it is hashed for storage in sort order, making it fast to find a particular file record. This mechanism works well for all files except the case where the name contains a tilde character not inserted by MW Visual SourceSafe or MS SourceSafe.

The reason this case doesn't work is because the characters following the tilde are considered to be sequencing information relating to the compressed name. Thus, when you have a file whose name begins with a tilde (or for that matter has a tilde anywhere in it), you end up with the sort key being generated incorrectly. The upshot is that the project file is now missequenced according to the sort keys and that resequence won't operate on the files

22. When I modify a resource file with a resource editor, why doesn't MW Visual SourceSafe check in the updated resource file when Use_CKID = Yes?

Answer: Because the CKID resource in the resource file was not changed.

There is an anomaly in using CKIDs to provide modification information on resource files in a MW Visual SourceSafe project. This is not a problem with standard files that only use the data fork, only with files containing resources that are modified with resource editors.

Essentially, the problem presents itself when a client uses the setting Use_CKID = Yes.

When a file is checked out containing resources, then modified with a resource editor like ResEdit or Resorcerer, the CKID resource is not updated to reflect the modification automatically. The next time the file is checked back in, MW Visual SourceSafe matches the file's CKID with its own copy of the file's CKID in the project database, finds no difference, and doesn't update the file in the project. Result, the changes are not added to its internal copy.

Solutions
^*If You Must Use CKIDs - ensure that you change the modifyreadonly setting in the CKID resource within the resource file before attempting to check it back into the project database.

Alternately, you can create a new sub-project to hold all your resource files that require modification by a resource editor and set it not to use CKIDs for checkin comparison in your srcsafe.ini file or ss.ini file. In this example, all the files in the Proj directory will use CKIDs, while the files in the Proj/Rsrc directory will not:

NOTE: You should also set Honor_Timestamp to Yes when using CKIDs.

^*If You Don't Need CKIDs - just set Use_CKID = No in the srcsafe.ini or ss.ini file and the entire contents of the project file will be compared to the resident copy in the project database. Any changes will be noted and the project database updated with the new data in the file.

23. Is it possible to modify a file when I am off-line from the project database, and later check it in?

Yes, but you must exercise great care. Once you have reconnected to the project database, perform a checkout of the file without getting a local copy, then checkin the modified file. See "Retrieving Files" on page VPG-46 of the "Inside Metrowerks Visual SourceSafe for Macintosh" manual for details.

NOTE: If Multiple_Checkouts = Yes and Use_CKID = Yes, commands that can suppress local copies (like Get) can cause problems with modified files.

Imagine the scenario where you have two people accessing the same file which is currently at version 1. Person A checks the file out and Person B gets a copy of the file for review. Person A modifies the file and properly checks it back into the database as version 2. Person B decides to modify their local copy of the file, then checks the file out (version 2) while suppressing the local copy, and checks their local copy back into the database as version 3. In effect, Person B has over-ridden any changes made to the file by Person A. Person A's changes are now locked into version 2 of the file because Person B didn't know the file had changed.

24. MW Visual SourceSafe IDE plug-in refuses to allow me to add a file. What can I do?

Hold down the Command key and try again. If the CodeWarrior IDE becomes confused about a file's status, holding down the Command key while clicking the menubar will enable all VCS commands, allowing you to add your file.

25. After I add a file to MW Visual SourceSafe, where does the file go? Is the copy that I add the "real" copy, which MW Visual SourceSafe is simply pointing to? Or has it created a copy in another directory somewhere?

The master copy of the file does not exist in a directory at all. It exists in a project in a MW Visual SourceSafe database. The file you added still exists, but you can delete it from your directory if you like: MW Visual SourceSafe has the file available for you to work with at any time.

It is important to understand that a project is not a directory and a directory is not a project. Rather, a project is associated with a directory, such as your working directory or a shadow directory.

26. If I change a file, check it in to MW Visual SourceSafe, and then use the Difference command on that file, MW Visual SourceSafe displays the message The files are identical, in spite of my changes. Why doesn't MW Visual SourceSafe show me the changes I just made?

The key is understanding what the Difference command does. It compares MW Visual SourceSafe's most recent version of a file to the copy in your working directory. If you've just checked the file in, the two copies are identical.

One way to work around this is to use the Difference command before checking in the file; seeing your changes may also help you formulate your checkin comment.

After checkin, you can see your changes by comparing the current master copy of the file against the previous version, using the History command with the -d option to show line-by-line differences in the file.

27. After you have shared a file among a number of projects, you may lose track of which project the file actually started in. Which project is the “original” of the file: which project is it really in, and which is it shared to?

The file is in all the projects that share it: no project is “original”. MW Visual SourceSafe does not know which project the file was first added to. Internally, the file simply exists in the MW Visual SourceSafe database, and every project that shares it has a pointer to it.

28. Why doesn't my initialization variable work?

MW Visual SourceSafe has a host of initialization variables and configuration settings that you can use to control the way MW Visual SourceSafe works, and they are all accessible by editing a simple text file. However, it can be frustrating to place a variable into the file and then discover that it does not seem to be working.

There are several common causes of this problem:

• The variable is spelled incorrectly.
• Double-check the spelling.
• The variable is under the wrong header.
• The order of variables in the initialization file does not matter, but which project header a variable is under matters a great deal. Most variables can be set in one of two places: either at the top of the file (before any header), in which case the variable applies to all projects, or under a specific project header. If you place a variable under a header to which it doesn't apply, MW Visual SourceSafe ignores it.
• There are colons in a project header.
• The project header in an initialization file must exactly match the MW Visual SourceSafe name of the project: for instance, $/Gizmo/Doohickey. Even small changes, such as changing slashes to colons, will cause MW Visual SourceSafe to ignore the variable.
• You placed quotation marks around the value. Unless a particular variable specifies otherwise, do not use quotation marks around any variable or value in your initialization file.

29. I just installed MW Visual SourceSafe, why do I get the error message "Directory not found" whenever I execute a MW Visual SourceSafe command?

Your Project_Dir initialization variable may not be an absolute path.

30. Are there any network configurations that we should avoid?

You should currently avoid the following network configurations:

• InterCon NFS/Share, due to the limitations in number of files available on a mounted drive.
• Any case in which multiple transport protocols are used to access a single database. Examples include using multiple network hosts on a single platform (i.e. trying to use Samba and netatalk to share a single database simultaneously). The exception to this rule is Windows sharing with Appleshare hosting on NT 4.0, which is heavily tested.

	Metrowerks, Inc. 9801 Metric Blvd. Austin, TX 78758	phone: 800.377.5416 512.873.4700 fax: 512.873.4901	<sales@metrowerks.com> <http://www.metrowerks.com>
Download CodeWarrior Lite Today!

Copyright Metrowerks (c)1998 - 1999